出处：掘金

原作者：程序员龙燊

在 AI Coding 提效这件事上，我想我的经历让我有充分的发言权。今年上半年，作为团队中的校招新人，我承接了两位离职同事的业务模块。面对密集的需求，我不仅扛住了“以一当三”的交付压力，同时保证了线上零事故。这一切，离不开 Cursor 的深度辅助

Cursor 使用经验分享

重中之重：模型的选择

模型是 AI 的基座，地基不牢，地动山摇。在此直接上结论：无脑选择 Claude

这不仅因为在大模型代码能力评测中 Claude 持续领先（如上图所示），更是笔者自 Sonnet 3.5 版本发布以来，实际体验 Claude 在代码生成、逻辑理解与上下文关联方面的能力，相比同时期的模型，确实一骑绝尘

需要注意的两点：

1. 警惕 Auto 模式： 若账号用量不足，Cursor 会自动切换至 Auto 模式，此时可能分配到性能较弱的模型，输出质量会显著下降。该模式可用于技术交流，但不建议用于代码生成与编辑。这也是我升级了订阅计划的原因
2. 关注上下文长度： Cursor 会实时显示上下文使用情况。若接近限制，可主动选择支持更长上下文的模型，或开启多倍计费的 Max Mode 以扩展处理能力，避免上下文丢失带来的输出质量下降

Talk is cheap. Show me the code.

相信研发同学对这句话都不陌生。这句话，在此处不妨视作 Cursor 对我们提出的要求。与 Cursor 协作的第一原则是：能提供代码片段，绝不用文字描述；能用变量名指代的，绝不用中文名

手动添加上下文

1. 选中代码片段，点击“添加到聊天上下文”按钮（快捷键 Ctrl+I）
2. 若仅提问不希望 Cursor 改动代码，可使用 Ctrl+L
3. 在目录中右键点击文件或文件夹，将其加入对话
4. 在输入框中输入 @，手动选择要引用的文件或目录

尤其在涉及多文件改动时，主动告知 Cursor 相关文件路径，效果远优于依赖其自行检索

统一语义表达

在业务沟通中，请始终使用精准的变量名与 Cursor 交互。例如，在价格相关需求中，应直接使用 purchasePrice、price 等已有变量名，而非口语化的“到手价”、“原价”。这能确保 AI 在后续所有交互中对概念理解一致，无需反复推理映射关系

同样，在描述界面元素与交互逻辑时，精准引用标识符而非依赖自然语言描述，是提升 Cursor 理解准确度的关键

• 定位界面元素，应明确指出其 className 或 id，而非使用模糊的自然语言。 例如：❌ “那个下载按钮” → ✅ “类名为 .download-btn 的按钮” 或 “ID 为 #export-download 的元素”
• 描述交互逻辑，应直接提供回调函数名或方法名称，而非笼统描述行为意图。 例如：❌ “点击按钮后弹窗” → ✅ “在 handleConfirmClick 函数中调用 showModal() 方法”

这种方式能够有效避免界面中存在多个相似元素时造成的歧义，也便于 Cursor 直接在代码库中定位相关逻辑，实现精准编辑

如何定位故障？

在“AI 能否取代程序员”的持续讨论中，精准定位并修复线上故障一直被视作人类工程师的关键优势。其根本原因在于：AI 虽能较好地解析静态代码结构，却难以感知系统运行时的动态状态。而很多深层问题 —— 如内存泄漏、线程竞争、环境依赖异常等 —— 恰恰隐藏在静态代码与动态执行之间的鸿沟中，这构成了当前 AI 在故障处理中的认知边界

那么，我们如何为 AI 架起一座跨越这道鸿沟的桥梁？

答案正在于我们人类最熟悉的调试手段：日志。既然日志能够成为开发者和运行中系统之间的沟通媒介，那么它同样可以转化为 AI 理解运行时行为的关键信息来源

引导 AI 插入关键日志

当你发现某个功能异常，可指示 Cursor 在关键逻辑路径上添加日志点。只需简单指令，如：“请帮我在 xx 功能相关的函数内部添加 console.log，输出关键变量的值”

运行代码并捕获日志

执行添加日志后的代码，复制运行时所生成的完整日志输出

将日志与代码共同提交给 AI 分析

然后再将日志复制发送给 cursor，神奇的事发生了，本来它改动了几遍都没能解决的问题，一下就定位到了根因

技巧背后的逻辑

此方法之所以有效，是因为它将 AI 从纯粹的代码静态分析者，转变为了一个具备“运行时视野”的调试伙伴。通过日志，AI 能够：

• 追踪变量的实际变化轨迹
• 识别逻辑分支的真实执行路径
• 发现数据流与预期不符的具体位置

添加 Rules：让 AI 记住你的工程规范

在使用日志与 Cursor 协作调试时，我遇到了一个典型问题：项目中已有大量日志，新增的调试信息很快被淹没，难以快速定位。我希望 Cursor 在每次插入调试日志时，自动在开头附加 【xx 功能调试】 这样的标识，以便在控制台中快速筛选。但若每次对话都重复这一要求，既低效又容易遗漏

这时，Cursor 的 Rules 功能便可发挥关键作用。你可以在规则中固话这类常见的工程约束或团队规范，例如：

• always respond in 中文，永远用中文回复我
• 禁止使用嵌套的三元表达式，多层三元表达式请根据情况选择使用 if else 或者策略模式实现
• 你不需要关注格式化的问题，除非我主动让你修复格式化问题
• 不要删除代码中我没有主动让你修改的注释
• 修改完后输出直接输出修改总结，不要创建测试验证
• 当我让你打 console 追踪问题的的时候，请给这些 console 开头打上统一的标识以便我在控制台中搜索

Cursor 支持为不同项目配置独立的规则集，灵活适配各工程的特定规范。具体设置方法详见官方文档：Cursor - 规则

完成规则配置后，我们重新执行之前的调试对话。如下图所示，现在每个 console.log 语句的开头都已自动加上了对应的函数名作为标识，极大方便了在控制台中的筛选与查看：

集成 MCP：拓展能力边界

在使用日志辅助 Cursor 进行调试的过程中，我逐渐发现两个影响效率的典型问题：

• 手动复制繁琐：频繁从控制台复制日志再粘贴至 Cursor，本质上仍是一种重复劳动，与 AI 协作的自动化理念相悖
• 日志内容杂乱：控制台中的引用类型数据（如对象、数组）若不展开或格式不当，难以完整复制；同时，控制台自动插入的代码位置信息（文件路径与行号）常混杂在日志正文中，导致最终提供给 Cursor 的文本结构混乱、难以解析

上图正是这一问题的直观体现：日志中穿插了源代码位置，而对象数据未完整展开，这样的信息直接交给 Cursor，会影响其理解与推理的准确性

而此时，正是 MCP（Model Context Protocol）可大显身手的场景。 通过为 Cursor 配置浏览器 MCP 服务，我实现了工作流的质的飞跃：

MCP 赋予 Cursor 直接控制浏览器的能力，使其能够：

• 自动捕获页面截图
• 直接读取控制台日志
• 分析 DOM 结构

当前 Cursor 的浏览器 MCP 仅支持内置窗口与 Chrome。若你使用 Edge 或其他浏览器，可选用微软推出的 Playwright 作为替代方案

同时，主流前端工具已纷纷提供 MCP 或知识库。以 Ant Design 为例，将其官方知识库 LLMs.txt - Ant Design，添加到 Cursor 的指定位置：

添加后，Cursor 即可基于官方最新文档提供准确的组件使用建议

优先选用 AI “擅长”的技术栈

何为 AI “擅长”的技术栈？简单来说：React、TailwindCSS 属于 AI 表现优异的技术栈；微信小程序次之；而像 Taro、uni-app 这类一码多端的框架，则往往是 AI 的弱项

其背后的逻辑在于数据可见性：开源生态越丰富、网络公开样本越多的技术，大模型在训练时接触到的相关代码就越充分，生成质量自然更高。反之，闭源、文档稀少的场景，AI 由于缺乏学习材料，表现往往不尽如人意

在实际的 Taro 项目中，当我尝试让 AI 协助处理 H5、小程序与 RN 三端的代码适配时，其表现确实令人沮丧。我最常遇到的状况是：好不容易让 AI 修复了 H5 端的样式错位，转头就发现小程序端布局崩溃；当 RN 端的交互问题被解决后，H5 端又出现了新的渲染异常

因此，在 AI Coding 日益普及的背景下，我们不得不重新审视如 Taro、UniApp 等一码多端框架的效率等式：其带来的跨端便利，是否足以抵消因 AI 支持薄弱而导致的额外研发成本？这一点值得深思

破局之道或许在于深度拥抱 AI 生态。如果这类框架能官方的推出强大的 MCP 服务，将其多端差异和配置逻辑“结构化”地注入 AI 的认知过程，它们将有潜力从当前的“AI 洼地”转变为“智能跨端”的典范

反直觉：0-1 不难，1-100 更难？

读过不少 AI 编程文章的人都会发现，多数内容都在展示如何从 0 到 1 快速搭建应用。但实际上存在一个反直觉的真相：用 AI 从 0 到 1 并不难，真正难的是让它接手和维护存量代码

在新项目中，AI 面对的是清晰的上下文和现代技术栈。而在存量代码中，它需要理解混乱的命名、隐含的业务逻辑和特殊的实现方式，同时要避免“修复一个 bug 引入两个新 bug”的连锁反应。这就像让新人从头做项目，远比让他修改复杂的老系统要简单

要让 AI 有效接手存量代码，关键在于像帮助新人一样为它提供清晰的指引。核心方法有二：

为 AI 优化的代码注释

传统的业务背景介绍对 AI 帮助有限，应该采用更代码化的注释方式。避免长篇大论地介绍业务逻辑，而是清晰地指出代码和业务之间的关系，魔法数字的具体含义等

比如，不要写“这里是价格计算模块，因为历史原因需要区分新老用户”，而应该写“新用户(level=1)享受首单优惠，老用户(level>=2)按原价计算，优惠金额固定为 20”。重点注释魔法数字的实际含义、复杂条件判断的业务背景、接口字段的映射关系等

TypeScript 的天然优势

在接手现有项目上，TypeScript 有着得天独厚的优势。类型定义相当于强制展示了一遍代码结构，如果再加上每个变量的注释，就是现成的知识库

通过“精准注释 + 完整类型”的组合，即使是最复杂的遗留代码，AI 也能快速理解并安全修改，真正突破从 1 到 100 的瓶颈

AI Coding 时代，优秀研发需要哪些新特质？

聊了这么多 Cursor 的强大表现，难免让人心生疑问：研发是否正在被 AI 取代？恰恰相反，我认为 AI 正在急剧拉大开发者之间的能力差距。今年我司几乎人人都用上了 AI 编程工具，可能是 Cursor，也可能是 Joycode。但如果你去 review 团队中的代码，就会发现：强者的代码因 AI 而更优秀，弱者的代码因 AI 而更紊乱

结合实践中的经验，我总结了 AI 编码时代一名优秀开发者最应具备的几种核心能力：

有责任心，做代码的 owner

早期使用 Cursor 时，我常常陷入一种状态：AI 生成的代码占比太高，以至于我对新增部分失去理解和掌控。一旦被问及业务逻辑，或是出现线上问题，甚至会不知从何查起

这就像一位艺术家通过 AI 生成画作，很难像对待自己亲笔作品那样珍视并负责。我的改进方案是：在每次 Agent 完成编码之后，阅读其改动总结；在每次提交前，仔细 Review Cursor 生成代码的 Diff。这个过程强制我理解每一行变更，重新建立起对代码的掌控感

如上图，通常 cursor 在修改完成后都会自动生成总结（也可以通过添加 rules 控制），可以结合总结阅读 diff

代码品味，超越能跑就行

AI 生成的代码能运行、测试通过、上线不出事故，就足够了吗？如果你的技术认知水平在 AI 之下，无法判断其实现是否为最佳实践，就可能在系统中埋下无数隐患

举个例子，上周在使用设计稿 AI 转代码的时候遇到过一件事：

AI 将图中的商品列表拆分为多行布局 —— 一行图片、一行商品名、一行价格、一行按钮。然而，具备前端组件化思维的同学一眼就能看出，更合理的做法是将其封装为独立的商品卡片组件进行循环渲染：

尽管 AI 的产出在功能上可以运行，测试、产品与用户也难以察觉差异，但这样的结构严重缺乏可复用性。若未来其他页面需要复用相同样式的商品展示，我们将不得不重复编写样式与逻辑，违背了组件化的设计初衷

因此，我的建议是：坚持阅读高质量的代码，无论是优秀的开源项目，还是身边同事的成熟实现。遇到问题时，不必过度沉溺于调试错误实现，而应主动学习并理解最佳实践，勇于对不合理的代码进行果断重构

知识广度，做好技术决策

AI 在执行明确、具体的指令时表现更佳。这要求开发者既要有广泛的知识储备，又要能精准描述需求。研发就像行政总厨，而 AI 是精通各菜系的厨师 —— 总厨必须清楚做什么菜的时候，需要备哪些料，使用哪些厨具餐具，才能调度后厨高效产出

以前端开发为例，若能明确指定使用某个具体的 JavaScript 库，AI 的响应质量将显著提升。例如，在实现“前端解析 Excel 文件”功能时，若直接提示 Cursor 使用 xlsx 库，仅需二三十行代码即可获得目标数据结构：

而若未提供任何技术栈提示，AI 可能倾向于使用原生 JS 实现，代码量激增五倍以上，且逻辑复杂、未经充分验证

因此，持续在技术社区交流，关注经典工具与前沿方案，是提升技术决策能力的关键。 只有清楚“用什么”和“为什么用”，才能最大限度地发挥 AI 的编码潜力

表达精度，说 AI 听得懂的话

一个不善于使用搜索引擎的人，往往也难以通过 AI 获得理想结果。从模糊的需求到清晰的提示词，本质上是一种结构化与抽象能力的体现

继续用行政总厨的比喻：如果只说“番茄炒蛋要甜一点”，厨师会困惑 —— 是加糖还是加番茄酱？如果能明确“300 克番茄配 3 个鸡蛋，需要加 5 克白糖”，产出质量就有保障

精准表达的能力，与个人知识储备和语言表达能力相关，不好举例说明。建议有意识地阅读完整书籍、观看有深度的长播客，避免被短视频时代的碎片化表达削弱这种能力

对未来的展望

目前许多公司都在业产研测各环节大力推进“+AI”时，我不禁思考：AI 提效，是否真的等同于在现有流程的每个环节简单叠加 AI？

这让我想起从功能机到智能机的过渡时期：早期的触摸屏设备仍保留着大量实体按键，或者在屏幕底部保留了触摸版的菜单键和返回键，交互逻辑仍是旧时代的延伸。直到多年后，真正的全面屏与手势导航出现，才彻底释放了触摸交互的潜力

我们当前对 AI 的应用，或许正处在那个“仍带着实体按键”的阶段。 若只满足于在原有流程上“+AI”，恐怕难以触及其真正的变革性潜力。AI 不应仅是效率工具，更应成为流程重构与体验重塑的催化剂 —— 而这，才是我们接下来需要共同探索的方向